用手机代替扫码枪？我们这样搞定小程序对接ERP进销存的高并发难题
去年双十一前，一家做快消品仓储的客户找到我们，甩过来一个需求：仓库里两百多号临时工，每人发把扫码枪成本太高，损耗也大，想直接用他们自己的手机，扫包裹条码，通过微信小程序把数据怼进公司的ERP进销存系统里。听起来简单，不就是调个wx.scanCode嘛？但真动手了才发现，水太深。
客户用的ERP是本地化部署的老牌产品，进销存模块基于SQL Server，单据写入接口扛不住多少并发。平时PC端录入一天也就几千单，可大促期间，两百人同时扫码，峰值每秒进来的扫码事件能到三千次以上。手机摄像头扫出来的不光是数字，还有图片解码延迟、网络抖动，直接打过去，ERP的库存表当场锁死，差点跑路。
做软件系统集成十二年，类似移动化改造见过不少，但把手机扫码枪化且要硬刚高并发进销存的，确实考验细节。我们团队驻扎现场一周，摸出了套“端边云”协同的方案。核心思路就一条：别让手机直接碰ERP，中间加一层缓冲与调度。
小程序端我们做了极简处理。扫码动作用微信原生接口，但在js层加了本地校验，比如条码不符合客户规则的（长度、前缀），直接在手机上拦掉，不发包。同时，利用小程序的本地存储（相当于手机里的临时库），如果仓库WiFi信号飘了，扫码记录先存本地，每一条带个本地生成的UUID和毫秒时间戳。网络恢复了，按序补传。这招后来救了命，有个仓位死角没信号，工人扫了半小时，回来全同步上了，没漏一单。我们甚至优化了小程序的解码参数，把对焦区域缩小到屏幕中央条带，提速0.3秒，别小看这点，工人一天扫上千次，体验天差地别。
服务端这边，入口用了Nginx加自研的网关，令牌桶限流。重点在消息队列。我们架了台Kafka，手机端上报的扫码消息统一进topic。消费者端写了个适配器服务，专门对接ERP的进销存API。这里有个细节：ERP的写入速度上不去，我们就把短时间内的同类操作做批量合并。比如同一SKU的多次出库，在Kafka里窗函数聚合5秒，合成一张出库单，再调ERP接口。这样接口调用量直接砍掉八成。
另外，我们没完全依赖ERP的实时接口，而是落了一份镜像数据到自己云的PostgreSQL里，作为“已接收但未确认”的中间态。消费者线程从Kafka拉取后，先写中间态，再异步调ERP。一旦ERP返回成功，才把状态置为完成。这样即使ERP半夜维护挂了，白天攒的单子也不会丢，早上起来自动重推。这设计后来在客户一次ERP版本升级停机四小时里发挥了作用，恢复后两万单自动补齐。
幂等性必须提。手机扫码容易误触重复扫，我们在Redis里用Lua脚本做了原子计数，key是“条码 操作类型 分钟级时间”，超过一次就标记为可疑，进人工复核队列，不让它进ERP，避免库存虚减。
压测时我们模拟了1000台手机，用脚本回放扫码流，峰值TPS压到5000。我们自己的接收层CPU用到70%，Kafka毫无压力，后端适配器以恒定每秒30单的速度写ERP，老SQL Server居然扛得住，库存准确率99.99%。客户IT总监当场说，这比他们买一堆扫码枪舒坦多了。
复盘下来，手机当扫码枪不是不可以，关键在架构上别蛮干。小程序轻量、本地容错，中间消息队列削峰，ERP侧批量收敛。我们后来把这方案产品化，接金蝶、用友也都顺溜。如果你也在折腾仓储移动化，欢迎聊聊，少踩点坑。
微信号：18581869297
